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From  the  beginning  of  our  software  engineering  organization  to  our  current  Capability  Maturity  ModeP 
(CMM®)Level  5  quality  practices ,  the  implementation  of  the  software  configuration  management  (SCM)  discipline 
combined  with  management  and  engineering  practices  has  been  critical  to  our  weapon-system  software  sustainment 
activities.  The  focus  of  this  article  is  to  discuss  how  SCM  adds  value  to  our  organization  by  establishing  and  main¬ 
taining  continuity  of  the  engineering  workflow  and  provides  information  to  help  establish  a  strong  SCM  function 
in  maturing  software  organizations. 


The  word  “Kaizen”  is  a  Japanese  term 
used  to  define  the  discipline  of  con¬ 
tinuous  improvement.  For  example  when 
an  automotive  assembly  line  is  considered 
to  be  perfect,  it  is  pushed  past  its  limits 
until  a  malfunction  occurs;  the  anomaly  is 
found  and  corrected,  and  then  the  limits 
are  tested  again.  When  applied  in  the 
workplace,  Kaizen  means  continuing 
improvement  involving  everyone  -  man¬ 
agers  and  workers  alike. 

Software  configuration  management1 
(SCM)  is  the  one  discipline  where  devel¬ 
opment,  sustainment,  support,  and  soft¬ 
ware  Kaizen  are  accomplished  to  achieve 
quality  products.  SCM  defines,  imple¬ 
ments,  and  manages  product  life  cycles  by 
planning,  identifying,  controlling,  audit¬ 
ing,  and  improving  the  elements  by  which 
they  are  created. 

During  the  early  years  of  our  Software 
Engineering  Division  (TIS)  at  Hill  Air 
Force  Base,  Utah,  SCM  was  not  a  term 
commonly  used.  Most  engineers  were 
aware  of  SCM,  but  would  prefer  to  ignore 
it.  SCM  meant  processes  and  procedures. 
The  engineers  were  there  to  write  software 
and  did  not  want  to  be  bothered  with 
process  and  paperwork.  Every  individual 
or  team  had  their  own  way  of  doing 
things,  resulting  in  little  work  uniformity. 
They  did,  however,  want  to  have  quality 
software  with  as  little  rework  as  possible. 

This  desire  to  provide  quality  software 
forced  us  to  look  at  how  we  did  business 
and  to  search  for  ways  to  improve. 
Management  chose  to  use  the  Software 
Engineering  Institutes  Capability 
Maturity  Model®  (CMM®),  and  after  an 
initial  review  began  building  toward 
process  improvement.  This  decision  really 

®  The  Capability  Maturity  Model  and  CMM  are 
registered  in  the  US.  Patent  and  Trademark  Office. 


introduced  SCM  as  a  key  process  for  bet¬ 
ter  software  to  everyone  within  the  divi¬ 
sion.  In  order  to  become  a  CMM  Level  2 
organization  we  needed  to  have  consistent 
policies  for  managing  our  software  proj¬ 
ects.  The  standards  set  by  the  CMM  for 
this  level  were  requirements  management, 
software  project  planning,  software  project 
tracking  and  oversight,  software  subcon¬ 
tract  management,  software  quality  assur¬ 
ance,  and  SCM. 

During  our  CMM  implementation, 
software  quality  assurance  became  tied  to 
SCM  and  evolved  as  a  major  player  with¬ 
in  the  structure  of  the  organization.  This 
was  not  an  easy  road  for  the  SCM  team. 
Many  people  within  the  division  did  not 
want  the  change  and  did  not  want  the 
extra  demands  that  SCM  would  put  on 
them.  It  meant  being  accountable  for 
every  line  of  code  as  well  as  documenting 
every  change. 

Until  this  point,  each  engineer  was 
accountable  for  his  or  her  own  configura¬ 
tion  management.  Now  it  was  necessary  to 
have  a  separate  group  of  individuals  with 
the  sole  purpose  of  providing  quality 
assurance  as  well  as  managing  the  elements 
of  each  project  injected  into  the  processes. 

It  meant  following  a  process  that  was 
rigid  enough  to  keep  everyone  on  the  same 
track,  but  flexibile  enough  to  allow  each 
team  to  develop  its  products  based  on  cus¬ 
tomer  demands.  Over  time,  SCM  has 
become  the  discipline  that  assures  quality 
software.  In  short,  SCM  has  become  the 
glue  to  an  organization  that  produces  qual¬ 
ity  products. 

Developing  the  Glue 

During  the  developmental  stages  of  our 
weapon-system  software  activities,  SCM 
plays  a  major  role  in  planning  and  manag¬ 


ing  the  schedules  and  milestones  used  dur¬ 
ing  the  project  life  cycles,  as  well  as  identi¬ 
fying  product  configuration  items  (CIs). 
Within  TIS,  SCM  defines  and  records  the 
origin  and  details  involved  in  the  incep¬ 
tion  of  the  product  by  establishing  base¬ 
lines.  When  SCM  disciplines  are  used  dur¬ 
ing  this  initial  developmental  stage  of  the 
product  life  cycle,  it  is  comparable  to  the 
parable  of  the  man  who  built  his  house 
upon  the  rock.  A  solid  SCM  discipline 
provides  a  firm  foundation  upon  which 
software  development  and  sustainment  are 
achieved. 

It  is  during  the  sustainment  stage  of 
weapon-system  software  activities  that  the 
SCM  discipline  provides  consistency  and 
strength.  It  is  no  longer  adequate  to  simply 
create  a  product  using  a  set  of  established 
ground  rules  and  guidelines;  now  a  struc¬ 
tured  enforcement  of  processes  is  a  must. 
SCM  provides  continuity  to  the  workflow 
by  establishing  the  processes  and  proce¬ 
dures  for  controlling  and  auditing  CIs 
throughout  the  product  life  cycle  to  ensure 
quality,  integrity,  and  accountability  levels 
are  met  and  maintained. 

SCM  plays  an  integral  part  in  schedul¬ 
ing,  attending,  and  recording  pertinent 
information  during  the  definition  portion 
of  the  project.  SCM  enhances  the  sustain¬ 
ment  stage  of  the  product  by  carefully 
tracking  each  software  activity,  thus  blend¬ 
ing  in  integrity  and  quality  through 
repeatable  auditing  and  data  control. 
Establishing  traceable  metrics  to  track 
costs,  identify  weaknesses,  and  determine 
recovery  capabilities  ensures  SCM  as  a 
value-added  entity  to  the  product  life  cycle 
of  our  organization.  It  assures  that  every 
requirement,  problem,  action  item,  etc.,  is 
tracked  to  closure,  and  that  metrics  data 
for  each  of  these  activities  are  updated. 
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Figure  1: 

Sample  Project  Report 

SCM  maintains  a  configuration  status 
accounting  (CSA)  record  of  requirements 
compliance,  cost  control,  source  lines  of 
code,  and  more.  This  data  is  used  in  infor¬ 
mation  exchanges  such  as  program  manage¬ 
ment  reviews  to  make  well  thought-out, 
informed  decisions.  SCMs  data  manage¬ 
ment  of  workflow,  as  well  as  maintenance 
of  product  life  cycles,  provides  sustainment 
for  past,  present,  and  future  projects. 

The  Life  Cycle  Workflow 

Within  our  organization,  the  SCM  func¬ 
tion  defines,  implements,  and  manages 
product  life  cycles  by  planning,  identify¬ 
ing,  controlling,  and  auditing  the  current 
workflow.  Having  a  well-defined  process 
has  enabled  us  to  adapt  new  hardware  and 
software  workloads  into  our  organization¬ 
al  workflow. 

One  thing  that  has  proven  to  be  very 
beneficial  to  our  organization  is  the  ability 
to  tailor  our  formal  configuration  manage¬ 
ment  (CM)  process  to  the  needs  of  each 
individual  project.  This  way  each  individ¬ 
ual  team  does  not  have  to  adhere  to  strict 
procedures;  instead,  each  team  is  allowed 
flexibility  within  their  own  programs. 
SCM  has  been  very  helpful  to  each  team 
in  setting  up  procedures  that  comply  with 
the  process,  but  also  fit  individual  needs. 
Following  is  an  outline  of  that  workflow 
process: 

Planning:  Management  utilizes  SCM  to 
establish  and  maintain  CM  and  project 
plans  that  define  project  activities  and 
deliverable  work  products.  This  includes 
processes  and  procedures  for  the  life  span 
of  the  project.  SCM  is  used  to  attend  and 
record  project  directives,  schedules,  data 
requirements,  peer  reviews,  and  configura¬ 
tion  control  boards  (CCB).  These  boards 
define  milestones,  deliverable  work  prod¬ 
ucts,  and  cost  and  schedule. 

Within  our  organization,  the  CCB  is 
held  prior  to  initiation  of  any  work  to 
define  requirements,  schedules,  and  deliv¬ 
erables,  which  are  incorporated  into  a 
project  directive  and  project  requirements 
document.  These  signed  documents  repre¬ 
sent  the  agreement  between  our  organiza¬ 
tion  and  our  customer  defining  project 
milestones  and  deliverables.  CM  config¬ 
ures  these  documents  for  referral  through¬ 
out  the  life  of  the  project,  and  these  docu¬ 
ments  are  reviewed  periodically  for  addi¬ 
tions/deletions. 


Identifying:  Upon  completion  of  the 
upper  level  planning,  the  CSA  database  is 
populated  by  SCM  to  begin  the  task  of 
identifying  each  configuration  item  and  to 
begin  gathering  metrics  for  the  life-cycle 
updates.  By  obtaining  metrics  for  pro¬ 
posed  work  products,  SCM  provides  man¬ 
agement  and  engineering  with  the  neces¬ 
sary  data  to  make  judicious  decisions 
regarding  weapon-system  software  sustain¬ 
ment  activities.  This  is  the  heart  of  the 
continuous  process  improvement  of  our 
Level  5  organization. 

The  SCM  team  works  with  the  pro¬ 
gram  managers  to  identify  the  projects 
CIs.  SCM  populates  the  tracking  databas¬ 
es  by  creating  work  products  and  their 
related  data  management  objects  and 
ensures  that  all  requirements  approved 
during  the  planning  state  are  incorporated 
into  the  update.  This  requires  creation, 
maintenance,  and  closure  of  work  prod¬ 
ucts  for  schedules,  engineering  change 
proposals,  system  design  change  requests, 
subsystem  design  change  requests,  soft¬ 
ware  change  requests,  source  lines  of  code, 
etc.  The  database  then  provides  pertinent 
information  for  accumulating  proposed 
weapon-systems  upgrades. 

Our  organization  uses  our  CSA  system 
to  record  many  types  of  metrics  as  well  as 
actual  man-hours  and  lines  of  code  dedi¬ 
cated  to  each  change  request  produced. 
These  actual  metrics  are  later  used  when 
accessing  assets  and  manpower  for  new 
workloads.  Figure  1  is  a  sample  project 


report  that  includes  the  project  identifier, 
project  name,  engineer  assigned  to  the 
project,  man-hours,  lines  of  code,  and 
other  information  that  may  be  required 
during  project  development.  There  are 
several  other  reports  that  can  be  pulled  to 
show  the  status  of  projects,  percent  com¬ 
plete,  and  other  valuable  metrics. 
Controlling:  SCM  enforces  control  of  CIs 
by  establishing  processes  and  procedures 
to  maintain  accountability  of  configured 
software  enhancements  throughout  the 
life  cycle  of  the  upgrade.  Incremental  con¬ 
figuration  at  each  stage/milestone  ensures 
incorporation  of  approved  source  code 
and  maintains  traceability  of  known 
anomalies.  Within  our  organization,  the 
CM  functions  to  update  the  CSA  database 
at  intervals  during  the  product  life-cycle, 
providing  a  current  snapshot  of  the  pro¬ 
gram  at  any  given  time.  This  means  that 
when  addressing  both  current  and 
archived  projects,  the  historical  data 
regarding  incremental  releases  describes 
during  which  phase  anomalies  were  iden¬ 
tified,  along  with  in  which  release  the 
anomalies  were  corrected. 

Figure  2  (see  page  6)  is  an  example  of 
a  Software  Change  Request  (SCR)  form  as 
it  is  recorded  within  our  database.  Within 
this  process  several  metrics  are  recorded 
for  future  use.  Dates  are  tracked  as  each 
milestone  is  passed  such  as  the  completion 
of  a  final  peer  review  and  the  approval  of 
the  CCB,  as  well  as  the  man-hours  spent 
reviewing  SCRs,  time  spent  in  peer 
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Figure  2:  Software  Change  Request  (SCR)  Form 


reviews,  number  of  action  items,  their  pri¬ 
ority,  source  lines  of  code,  and  memory 
changes. 

Anomalies  are  found  during  various 
testing  phases.  As  they  are  detected  the 
engineer  responsible  for  finding  the  error 
enters  them  into  the  database.  The  database 
assigns  the  anomaly  a  tracking  number  after 
which  the  anomaly  becomes  a  configured 
item.  SCM  tracks  the  error  until  it  is  fixed 
or  determined  not  to  be  an  error.  Figure  3 
is  an  example  of  a  report  used  to  show  the 
status  of  anomalies. 

Auditing:  SCM  produces  audits  at  incre¬ 
mental  steps  throughout  the  software¬ 
building  process  to  ensure  quality,  integrity, 
and  adherence  to  established  processes  and 
procedures.  Additionally,  SCM  incorpo¬ 
rates  quality  assurance  throughout  the  life 
cycle  of  the  product  by  being  a  separate 
entity  and  maintaining  continuity  and 
accountability  of  the  engineering  work- 
flow.  Our  CM  processes  include  audits 
and  quality  checks  ensuring  that  specifica¬ 
tions  are  being  updated  incrementally  as 
software  lines  of  code  are  being  developed. 

An  example  of  these  audits  within  our 
organization  occurs  after  a  change  request 
has  been  reviewed,  comments  recorded, 
and  the  author  has  accomplished  a  re-edit 
to  include  peer  review  comments.  Our 
peer  review  process  requires  that  an  audit 
of  the  document  be  performed  to  ensure 
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that  the  author  incorporated  all  the 
approved  changes.  If  the  audit  is  not 
passed,  the  change  request  repeats  this  step 
of  the  process. 

One  of  our  lessons  learned  occurred 
when  a  customer  provided  us  with  docu¬ 
mentation  that  required  an  upgrade  prior 
to  releasing  new  software.  The  customer 
requirements  were  vague  and  undefined 


and  did  not  include  all  Cl  and  identifiers 
needed.  Additional  hardware  modification 
requirements  were  not  identified  until 
after  we  began  upgrading  the  software. 
Identifying,  correcting,  and  implementing 
the  anomaly  at  such  a  late  date  impacted 
the  software  release  cycle.  To  prevent  this 
anomaly  from  reoccurring,  a  corrective 
action  to  tailor  SCM  processes  resulted  in 
a  preliminary  review  of  all  documentation. 
This  has  eliminated  90  percent  of  the 
problems  we  had  previously  encountered. 
This  resulted  in  the  CCB  receiving  a  bet¬ 
ter  product  to  review  and  more  accurate 
estimates  of  program  cost/schedule. 

Tools  and  Metrics 

Tools  are  one  of  the  key  capabilities  with¬ 
in  our  software  sustainment  environment. 
Tools  provide  the  identification  and  con¬ 
trol  of  the  software  and  its  related  compo¬ 
nents  as  they  change  during  the  software’s 
life  cycle.  There  are  numerous  off-the-shelf 
SCM  tools  available  in  todays  market, 
some  of  which  we  use  in  our  organization. 
But  we  have  developed  many  organic  tools 
to  comply  or  adapt  specifically  to  our 
processes  and  corporate  culture.  There  are 
traditional  CM  tools  that  provide  check¬ 
in/check-out  control  of  code  as  well  as  the 
ability  to  compile  or  build.  Within  our 
organization  we  have  tools  that  provide 
process  management  such  as  the  ability  to 
track  anomalies  and  provide  problem 


Figure  3:  Anomoly  Status  Report 
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Figure  4:  Operational  Flight  Program  Tape  History 


reports.  We  also  have  commercial  off-the- 
shelf  tools  that  have  been  tailored  to  fit 
into  our  process  and  provide  us  with  the 
necessary  quality  checks  and  balances. 

One  of  the  key  areas  within  SCM  is 
status  accounting.  To  have  true  CM,  tools 
are  required  to  track  the  status  of  all  CIs 
as  well  as  problems  or  anomalies.  We  have 
developed  tools  within  our  organization 
that  provide  the  ability  to  track  several 
complex  systems  as  well  as  to  collect  data 
and  generate  numerous  reports.  These 
tools  also  provide  versatility  in  adapting 
to  a  variety  of  different  workloads.  One  of 
the  advantages  of  an  organic  tool  is  the 
ability  to  adapt  or  to  change  the  tool  as 
new  requirements  come  in  or  as  processes 
are  updated. 

An  example  of  a  new  requirement 
added  to  our  database  recently  is  the  Tape 
History  dialog  box  shown  in  Figure  4. 
This  history  helps  us  to  track  the  baseline 
used  to  develop  the  current  update  of  the 
Operational  Flight  Program  (OFP).  It 
tracks  all  version  releases  of  the  software 
identified  by  the  OFP  Identification 
Number  and  the  dates  they  were  com¬ 
piled.  As  a  result  this  has  helped  us  to 
track  baselines  for  individual  subsystems 


and  enables  us  to  pull  reports  for  those 
who  need  this  information. 

Throughout  the  different  stages  of 
process  improvement,  from  being  a 
CMM  Level  1  to  a  CMM  Level  5  organ¬ 
ization,  we  have  learned  many  valuable 
lessons.  One  of  the  most  valuable  being 
the  importance  of  creating  your  processes 
and  then  buying  or  developing  a  tool  that 
compliments  that  process.  If  you  buy  a 
tool  without  knowing  where  you  are 
going  and  what  your  overall  goals  are,  you 
end  up  having  to  adapt  your  process  to  fit 
the  tool.  That  may  not  be  the  best  for 
your  organization. 

One  of  the  benefits  of  a  good  status 
accounting  tool  is  the  metrics  and  reports 
that  can  be  obtained.  This  has  been  very 
beneficial  to  our  organization  and  to  our 
customers.  We  are  able  to  track  estimated 
costs,  man-hours,  source  lines  of  code, 
anomalies,  memory  requirements, 
rework,  and  much  more.  This  gives  us  the 
ability  to  compare  estimated  data  to  actual 
data.  It  is  this  historical  information  that 
gives  us  a  solid  track  record  and  helps  us 
greatly  in  bidding  on  future  workload,  as 
well  as  supplying  our  customers  with  infor¬ 
mation  in  creating  project  requirements. 


Training 

Training  for  each  member  of  the  SCM 
team  is  a  must.  SCM  is  an  evolving  field. 
Not  only  is  it  necessary  to  keep  up  with 
new  ideas  and  tools,  but  to  keep  up  with 
the  industry  on  how  SCM  is  being  inter¬ 
preted  by  the  world  or  even  in  other  parts 
of  our  own  division.  In  order  to  provide 
customers  with  current  processes  and  pro¬ 
cedures,  we  must  be  aware  of  changes  and 
improvements  made  within  the  industry. 
This  enables  assigning  appropriate 
authorities  and  responsibilities  to  all 
SCM  activities  within  our  organizations. 

Management,  engineers,  and  configu¬ 
ration  managers  must  understand  the 
processes  within  their  respective  organiza¬ 
tions.  It  is  necessary  to  be  knowledgeable 
enough  to  tailor  SCM  practices  to  the 
needs  of  each  customer/workload. 
Configuration  managers  are  involved  in 
all  stages  of  development;  they  must 
become  an  integral  part  of  the  process. 
Here,  they  are  depended  on  for  their 
expertise  in  decision  making  to  facilitate 
process  improvement  and  provide  a  qual¬ 
ity  assurance  role.  Detailed  knowledge, 
formal  training,  and  on-the-job  experi¬ 
ence  result  in  the  ability  to  recognize 
problems  -  to  stop  work,  address  issues, 
correct  problems,  and  continue  moving 
ahead.  When  problems  are  encountered, 
knowledgeable  configuration  managers 
are  invaluable  in  resolving  issues.  Some 
training  examples  that  benefit  our  organ¬ 
ization  follow: 

•  First  is  mentorship  between  trained 
pesonnel  and  new/un  trained  personnel. 

•  Second  is  CM  training  courses.  These 
courses  give  a  broad  overview  of  SCM 
and  usually  benefit  anyone  interested  in 
becoming  knowledgeable  of  basic  SCM 
fundamentals. 

•  Third,  and  most  importantly,  is  on-the- 
job  training,  which  provides  the  most 
insight  to  SCM  processes  and  proce¬ 
dures. 

Properly  trained  SCM  personnel 
result  in  procedures  that  produce  repeat- 
able  quality  products.  Members  of  the 
SCM  team  are  not  technical  or  engineer¬ 
ing  people.  The  team  is  comprised  of 
individuals  who  are  competent  in  the 
skills  needed  to  provide  insight  and  back¬ 
ground  to  SCM  policies  and  procedures. 
Within  our  organization,  this  has  provid¬ 
ed  an  avenue  for  individuals  to  pursue  the 
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set  criteria  for  developing  configuration 
management  skills,  which  results  in 
opportunities  for  advancement.  Proper 
training  creates  knowledgeable  configura¬ 
tion  managers  who  can  teach  others  the 
value  of  the  SCM  discipline.  Trained  con¬ 
figuration  managers  perform  their  duties 
with  confidence  and  professionalism. 
These  software  professionals  make  the 
SCM  discipline  a  vital  function  in  matur¬ 
ing  a  software  organization. 


Conclusion 

Maintaining  a  SCM  discipline  is  critical 
to  our  CMM  Level  5  software  sustain¬ 
ment  activities.  Proper  implementation  of 
SCM  enables  us  to  plan,  identify,  control, 
and  audit  product  life  cycles.  SCM  along 
with  management  and  engineering  guide 
our  organization  to  continuously  improve 
our  ability  to  meet  expectations  of  high 
quality,  low  cost,  and  on  time  deliveries. 


Continuous  improvement,  or  Kaizen,  can 
be  achieved  when  practitioners  are  pro¬ 
vided  with  proper  tools,  adequate  train¬ 
ing,  and  empowered  with  a  quality 
process. ♦ 

Note 

1 .  Configuration  management  definition 
is  as  defined  by  the  Configuration 
Management  Training  Foundation 
(CMTF),  Magalia,  Calif. 
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